Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1199/898

Internet Message Format | 1994-08-27 | 3.6 KB

From: Stephen Usher <[e-mail]>
Subject: Re: LINUX Filesystem standards
Date: Wed, 19 Jan 1994 08:19:01 +0000 (GMT)
In-Reply-To: <[e-mail]> from "Michael Hohmuth" at Jan 18, 94 11:25:04 pm
Mime-Version: 1.0

>> [ Linux Filesystem Structure ]
>
>They've done the work for us..  I think we should use this document as a
>very good starting point.

Hmm.. I'm not TOO sure about this. Linux is VERY SYSVr4-like in its
structure, MiNT and the environment we have so far is more BSD-like. Also,
the Linux file structure is a right pain to use in my experience,
everything's in the "wrong" place.

If we are doing this to assist porting of programs then I suggest that we
match our directory structure closely to that of the type of system our
library most looks like.. which is, in general, more BSD than SYSV.

>All that's left to do for us is to find any MiNT specifics and integrate
>them into this structure.
>
>So I would suggest:
>
>o /usr/src/linux becomes /usr/src/mint

Why is there a need to clarify where the source goes with MiNT? It's not as
if you can auto config the kernel, build it, install a boot block, copy the
kernel to the boot directory and reboot all from within MiNT using a script.
It would be nice if MiNT had a reboot system call, but it doesn't.

>o /boot points to the MiNT boot directory (which has to reside on a Tosfs
>  partition, currently); this includes mint.cnf and minix.xfs

Why not fit in with other systems and call this /sbin?

>o I still like the /usr/kits + /var/kits idea..  What about
>  /usr/kits/multitos?

Hmm.. sounds a bit tacky.. if you're going SYSVr4-like put them under /opt,
except for the compilers which go under /usr/ccs.

>One more question:  Can GEM programs be integrated in the structure?
>Perhaps /usr/gem/<kit> or /usr/kits/<kit> something?

Following SYSVr4 that would be /opt/ATARwgem/... Note the silly package
name.. this is the new standard package naming convention defined by, I
think, SVID or something just as silly.

>What I also like about this draft is that it doesn't prescribe whether
>/sbin/rc.* or /sbin/rc?.d/* is the standard.  :-)

For it to be SYSV-like it should be /etc/rc?.d. Each of the directories hold
the scripts which are run when you change run-level. In fact, they merely
contain links into erm.. canne remember the directory name.. where the real
scripts are held. There are two types of scripts in the directories, those
which are used to kill services and those which start them up.. how they are
called depends upon thier name. The names have the structure [KS]xxname
where K means kill script, which is called with the argument "stop" and S
means start script, called with the argument "start." xx is the priority
number. The scripts are run in priority order, starting with 1 and going up
to 99.
eg. to go to run level 3, say, the following is done by init (in pseudo csh):-

$stop-scripts = (`ls /etc/rc3.d/K* | sort -n`)
foreach script ( $stop-scripts )
  sh $script stop
done
$start-scripts = (`ls /etc/rc3.d/S* | sort -n`)
foreach script ( $start-scripts )
  sh $script start
done

This seems better than the BSD way of doing things until you try to
administer it... brr... yuck. I've had to do it on a real SYSVr4 box. The
BSD way is simpler and easier to understand.

>
>Michael
>--
>Internet: [e-mail]
>

Steve

--
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: [e-mail] (JANET) [e-mail] (Internet).
Tel:- Oxford [phone] (UK) or [phone] (International).